Very nice.

Perhaps we could provide a few concrete examples of ways this has saved us, or ways we plan to use this.

• we're planning to use the community build to guide the source compatibility of the new collections (in addition to checking their performance)
• we can test out new releases, or flavours (Graal, OpenJ9) of the JVM in order to find bugs or other incompatibilities that need to be addressed.

Is it worth a shout out to MiMa? I wonder if it's worth stating that the Scala community build compiles project code, compiles and runs its tests, and therefore tests source compatibility and runtime behaviour, leaving binary compatibility concerns to MiMa?

I mention it because in sbt land we're always torn about wanting to ensure we definitely don't break bincompat in the already-published plugins, but at the same time we don't want to majorly inconvenience build users and plugin authors with a big impacting source incompatibility.

Very nice Seth! I just added two little nit picks that make things look clearer to my eyes, but you don't need to act on them if you don't want to. Feel free to merge when ready! :)

Also–thanks a lot, guys, for writing a blog article!

I've pushed one more commit that:

• makes Heather's suggested changes
• adds a "Has it helped?" section along the lines suggested by Jason

Perhaps we could provide a few concrete examples

the text I added still isn't super concrete, but I'm going to keep this in mind for future blog posts about the community build. I'm envisioning a once- or twice-yearly blog post, probably on the short side, that says what projects we've added and includes some stories about how the build has helped us recently.

Is it worth a shout out to MiMa?

Hmmm... yeah, I was tempted to delve a little deeper into how source compat and bincompat differ, why it's so important that dbuild rewires inter-project dependencies rather than just building everything separately, and so forth. But I feel like this post is probably already long enough.

I think I'll keep these topics in mind for a future blog post. Either a sequel to this one, or perhaps a blog post about our QA efforts more generally — community build, MiMa, Scabot, partest, the stability test in bootstrap, etc etc etc, a survey of that whole landscape.

added a bit more "benefits" text:

+Library authors have also benefited.  The community build has
+often provided early warning of compatibility issues because
+of changes to Scala or changes to other libraries.  It has helped
+maintainers standardize their builds, keep their dependencies
+up-to-date, identify flaky tests, and shake out assorted other
+issues.

now live at http://scala-lang.org/2018/01/16/community-build-growth.html

tweeted: https://twitter.com/scala_lang/status/955543744735985664

historical footnotes, to be entered into the Chronicles of Scala (unabridged 83-volume edition):

• the oldest related thing I found was 2010's "Fresh Scala": https://dzone.com/articles/call-fresh-scala
• Josh Suereth was working on this as early as 2012; I found a September 2012 (in runup-to-Scala-2.10 days) scala-internals post where he writes "Currently the community build resides on my machine, but will be migrating to a public jenkins when ready"
• the oldest commits in the repo are from 2013; at that time, 21 projects were included
• the initial public announcement wasn't until September 2014, by @gkossakowski: https://groups.google.com/forum/#!msg/scala-internals/n9K7V2aSp8M/IEujiFoOEREJ
• I wrote a progress update for scala-internals in November 2015: https://groups.google.com/forum/#!msg/scala-internals/uK2759nBho0/PovT7HlIBgAJ

I ended up rather arbitrarily choosing 2013 as the start date in the blog post, since it wasn't clear to me if the 2013 thing was descended from Josh's 2012 work or not.

The biggest reason I waited so long before writing this blog post is a stupid reason: I wanted accurate LOC counts before blogging, but procrastinated endlessly on actually writing the cloc plugin. (Which, when I finally did it, was only a day's work, so go figure.)